Embodiments of the present invention relate generally to methods and systems for implementing service level consolidated user information management and more particularly to providing a policy enforcing mechanism to manage routing of requests related to user information.
As an ever increasing number of services are being offered by various network providers, there is a corresponding increase in the number of systems, devices, applications, and components that utilize and store data for customers. Data typically is stored in databases as either structured or unstructured data. Directories (e.g., Lightweight Directory Access Protocol (LDAP) directories) can be used to store the data, as well as various schemas. XML data can be stored in XML-aware databases and repositories such as are found in XML Data Management (XDM) servers allow storage and exchange of XML data. Other examples include dynamic data such as network information (e.g., Home Subscriber Server (HSS) data, Home Location Register (HLR) data), presence information, location from network resources, etc. Data that may be considered for aggregation includes: Operations Support System (OSS) and Business Support System (BSS) data such as subscription data, account information, billing information, bills, inventory of assets, etc. (all of this information can be represented in TMF Shared Information/Data (SID) data model). All of these are particular examples of data repositories.
Existing systems used to capture, describe, present, etc. user profiles do not provide a view or aggregation of data from other domains, where data manipulation can be accomplished, accompanied by, or conditioned by execution of a policy (i.e., any combination of any condition and any action) that may call other systems to perform tasks that may update or result in updates of the data as needed, and that provide a view of the updated results or that may call other systems to perform tasks as a result of the update. Typically, these other systems are the “master controller” or “owner” of the data that is viewed. Data manipulation then is typically done as a request to change data in a system, a security check or identity authentication/validation, and a change of data by the database or repository. Such approaches can lead to problems in that changes made in one system might not align or be consistent with other systems using the same data, or consistent with related data in the same or other systems. As such, when a change takes place, the other data should be changed by other processes that result from the change or processes should be able to be initiated which result from the change to ensure that the other systems are properly updated.
Certain information thus overlaps or is related to other information stored for different services or in different repositories. Unfortunately, it is usually not practical for most entities to rewrite the schemas or redesign all the systems and services to use a common data model, single repository, single point of access, etc. As such, there typically is no way to easily treat the various repositories as a single data source that is readily available to applications, users, etc.
A significant problem thus exists in the fact that updating information in one data repository may require corresponding changes or updates in other repositories and/or running processes/workflows, with each repository storing information for multiple applications. In order to update data in a repository, the overall system assumes that several processes, workflows, applications, or at an initial or intermediate step, and that these applications have executed their own processes may have changed the context or data elsewhere. As such, these flows are not triggered and must separately manually (e.g., via a check list or the like) or consistency of the data must be periodically checked and updated as a result. So currently there are often many inconsistencies as a result, at least till reconciliation is performed. Or alternatively such approaches to integrate do not work and cannot be used to allow data updates via the profile. In other words, changes must be done on all systems when a change is to take place, as opposed to a request to a profile that carries the changes through to all systems effected.
For example, adding a subscription for a user in a BSS may also require updating support data and asset data (e.g. in an OSS, Network, or run time environment like service delivery platform (SDP)), as well as ensuring that some provisioning, activation, fulfillment, and/or billing takes place, as well as Enterprise Resource Planning Software (ERP) flows, (e.g., to supply equipment like delivering a phone, modem, or laying a cable, etc.) etc. If the data is allowed to be updated without following all such flows, data existing elsewhere (e.g. catalog or provisioning flows, new rates, inventories of assets associated to a principal (e.g. subscriber) or support details, etc.) may be dropped (i.e., not appropriately added/updated). Further, other data in the same repository that might need to be modified as a result of the change might not be modified appropriately. For example, an action such as creating a customer record in a customer database for a business such as a telecommunications service provider requires other updates or processes to be run for other systems, such as where a new customer must be added to the billing system in order to ensure that the customer will be billed for the service. The customer information must also be manually added to a support system so that the customer can receive necessary support, etc. It thus is not enough to simply update the information locally but all other necessary processes also must be executed in response to the update.
In the case of a service, when an update is to take place, it often is difficult to know where information is located, which information needed to be updated, as well as anything else that may need to be updated in order to maintain consistency of the entire system. This can significantly slow access, use, and changes to data such as subscription data. Many initiatives to offer such capabilities either fail or are extremely difficult to implement and/or integrate within a service provider's domain. Hence, there is value in offering a single API that allows the service to make queries without being made aware of specific details about the data, where the data is located, etc. In fact, many applications do not want to be made aware of the location of the data, how to keep the data consistent, what other OSS/BSS business flows to take into account, etc.
Hence, there is a need for improved methods and systems for implementing service level consolidated user information management.